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FOREWORD 


This  Workshop  on  Microprogramming  was  hosted  by  The  MITRE  Corporation, 
Bedford,  Massachusetts,  as  part  of  the  work  effort  for  Project  7120  of  the 
Electronic  Systems  Division.  This  report  was  prepared  under  contract 
number  F19(628)-68-C-0365. 


REVIEW  AND  APPROVAL 


Publication  of  this  technical  report  does  not  constitute  Air  Force  approval 
of  the  report's  findings  or  conclusions.  It  is  published  only  for  the  exchange 
and  stimulation  of  ideas. 

WILLIAM  F.  HEISLER,  Colonel,  USAF 
Chief,  Command  Systems  Division 
Directorate  of  Planning  and  Technology 


11 


ABSTRACT 

The  Workshop  on  Microprogramming,  sponsored 
by  the  ACM  with  the  cooperation  of  MITRE,  took  place 
at  MITRE  on  October  7-8,  1968.  This  paper  is  primarily 
an  historical  account  and  summary  of  the  workshop1 s 
business,  with  some  commentary. 
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SECTION  I 


1.0  INTRODUCTION 

The  Workshop  on  Microprogramming,  sponsored  by  the  ACM  with  the 
cooperation  of  MITRE,  took  place  at  MITRE  on  October  7-8,  1968,  The 
purposes  of  the  workshop  were  to 

•  identify  the  work  currently  being  done  in  the  field; 

•  promote  communication  between  microprogramming 
practitioners ; 

•  identify  promising  new  directions  for  investigation. 

Ninety-one  individuals  attended  the  workshop:  fifty-seven 
from  industry,  twenty-three  from  the  academic  world  or  university- 
associated  laboratories,  and  eleven  from  non-profits  or  government. 
Eighty-nine  were  from  the  United  States,  with  one  each  from  Italy 
and  Great  Britain. 

The  workshop  was  conducted  in  four  sessions.  The  first  three 
were  relatively  formal,  with  scheduled  speakers,  and  the  fourth  a 
less  formal  discussion  session. 

1 . 1  Current  Work 

Personnel  from  some  seventy-three  projects,  more  or  less, 
were  represented.  These  could  be  classified  roughly  as  follows: 

General  Study  or  Teaching  of  Microprogramming  (17) 

The  Design  of  Support  or  Automation  Processes  for 
Microprogramming  (10) 

The  Use  of  Microprogramming  for: 

Higher -Level  Language  Support  (8) 

Emulation  or  Extension  of  Instructions  Sets  (11) 
Direct  Applications  or  Process  Control  (13) 
Machine  Architecture  (14) 
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1.2  Communication 


Several  of  the  speakers  alluded  to  microprogramming  as  a 
"bridge"  between  hardware  and  software.  When  someone  schooled  in 
hardware  talked  about  hardware,  and  when  software  experts  discussed 
software,  the  conference  indeed  served  as  a  bridge  of  communication 
between  the  two  groups.  However,  whenever  interdisciplinary  aspects 
of  microprogramming  were  considered,  the  two  points  of  view  tended 
to  diverge.  In  these  cases,  the  workshop  served  as  a  forum  for  debate 
and  as  a  medium  for  mutual  astonishment,  if  not  enlightenment,  between 
the  hardware  and  software  schools.  Even  the  definition  of  micropro¬ 
gramming  was  not  resolved  because,  of  course,  each  tradition  sees 
this  new  technology  as  an  extension  of,  and  in  terms  of,  its  "old" 
technology  -  and  the  terms  differ.  The  subjects  of  who  should  do 
microprogramming,  how  he  should  do  it,  and  what  he  should  use  it  for, 
likewise  touched  off  much  controversy,  especially  in  Session  IV.  It 
should  be  remarked  that  the  present  writer  is  of  the  software  school. 

1.3  New  Areas  of  High  Potential  Payoff 

Emerging  from  the  workshop  were  two  central  themes  that, 
though  not  really  new,  will  clearly  become  more  important  as  the 
state  of  the  art  advances. 

One  of  these  might  be  called  "tradeoff  technology".  While 
several  papers  were  delivered  touching  on  the  subject,  and  while 
anguished  cries  would  be  heard  for  "guidelines"  on  the  use  of  micro¬ 
programming,  it  was  fairly  clear  that  no  practical  work  had  been 
done  towards  establishing  a  set  of  rules  for  drawing  near-optimum 
lines  between  hardware,  firmware,  and  software  portions  of  a  system. 
Almost  by  definition,  a  significant  payoff  will  reward  anyone  who  can 
dent  this  problem. 

The  other  subject  that  kept  coming  up  was  writable  control 
stores.  The  topic  generated  much  controversy  (Session  IV)  but  it  is 
obvious  that  writable  control  stores  will  be  produced  and  marketed 
as  soon  as  the  technology  and  market  support  them  -  and  the  market, 
it  appears,  is  waiting.  The  proper  use  of  this  facility,  so  as  to 
extract  from  it  a  maximum  measure  of  the  computer  power  and  flexibility 
it  seems  to  offer,  is  a  virtually  unexplored  technology. 
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SECTION  II 


2.0  SESSION  I 


"THEORY  OF  MICROPROGRAMMING" 

Chairman:  Professor  H.  Gray 

University  of  Pennsylvania 

Microprogramming  -  interpreted  as  implementing 
control  logic,  primarily  by  read-only  storage  - 
cuts  across  the  specialties  of  electronic  module 
design,  logic  design,  mechanical  languages,  pro¬ 
gramming,  and  system  architecture.  Microprogramming 
is,  therefore,  a  promising  means  for  designing 
integrated  hardware-software  systems.  In  this 
session  we  will  discuss  topics  fundamental  to 
microprogramming  and  these  related  specialties. 

—  from  the  Workshop  Bulletin 


M.  V.  Wilkes 

The  Growth  of  Interest  in  Microprogramming 

Appropriately  enough,  the  first  session  of  the  workshop  was 
opened  by  the  man  generally  credited  with  introducing  the  term 
microprogramming  in  the  sense  of  "implementing  control  logic  by  a 
control  store  -  usually  a  read-only  store". 

Professor  Wilkes  attributed  the  origins  of  microprogramming  to 
dissatisfaction  with  less  systematic  methods  of  system  design  and 
implementation.  He  traced  the  history  of  microprogramming  through 
an  early  period  of  interest  (early  1960* s)  and  through  successive 
periods  of  declining  and  (now)  resurging  interest.  The  intermediate 
decline  he  attributed  to  a  general  lack  of  successful  application  in 
the  early  days,  due  to  (1)  the  lack  of  a  fast  and  cheap  ROS ,  and 
(2)  the  shift  in  emphasis  away  from  machine  level  efficiency  that 
accompanied  a  growing  acceptance  of  higher-level  languages.  The 
present  renewal  of  interest,  he  claimed,  is  due  to  advances  in  memory 
technology  and  the  influence  of  the  IBM  360  architecture,  which 
demonstrates  the  feasibility  of  implementing  similar  instruction  sets 
in  small  and  large  machines. 
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Professor  Wilkes  recalled  his  earlier  opposition  to  modifiable 
control  stores  -  an  opposition  based  on  an  expected  ,fchaosM  that  would 
result  if  every  programmer  had  his  own  instruction  set.  He  softened 
this  position  only  to  the  extent  that  modification  of  the  control 
store  is  reserved  for  special  "system*1  programs  or  programmers  using 
now  we 11-unders toad  protection  techniques. 
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A.  Tonik 

Tradeoffs  for  When  and  How  to  Use  Microprogramming 


Mr.  Tonik  contrasted  the  "microbird 1 s  eye11  view  of  a  processing 
system  as  consisting  of  adders,  shifters,  etc.,  with  the  other  view 
which  sees  it  as  an  elaborate  array  of  logic  -  gates,  decoding  networks, 
and  the  like.  He  listed  the  liabilities  of  the  microprogramming 
approach  as  (1)  a  slower  cycle  due  to  the  need  for  control  memory 
access,  and  (2)  an  increase  in  hardware  (including,  presumably,  the 
control  memory  itself).  To  substantiate  the  latter,  he  estimated 
that  900  modes  in  a  small  conventional  machine  are  equivalent  to 
50,000  control  memory  diodes,  and  that  8,000  modes  in  a  large  con¬ 
ventional  machine  must  be  replaced  by  300,000  bits  of  control  memory 
to  obtain  an  equivalent  microprogrammed  machine  -  plus,  of  course, 
the  microprogram  control  circuits  in  both  cases. 

The  standard  list  of  advantages  for  microprogramming  as  a 
machine  design  tool  was  discussed:  the  ability  to  add  or  modify 
instructions,  precheck  a  design  by  simulation,  emulation,  etc. 

The  architecture  of  the  micromachine  itself  was  also  treated 
at  length.  One  of  the  questions  discussed  was  the  best  place  for 
keeping  the  address  of  the  next  instruction  -  (1)  in  the  instruction 
word  itself  or,  (2)  in  a  separate  counter.  The  figures  quoted  were: 
a  15-35%  larger  word  results  if  method  (1)  is  followed,  10-25%  more 
words  (the  unconditional  branches)  are  used  with  method  (2),  Although 
the  second  alternative  thus  seems  to  be  preferable  in  most  circumstances, 
Mr.  Tonik  pointed  out  that  one-instruction  subroutines  and  a  5-107o 
improvement  in  running  speed  can  be  realized  with  the  first  method. 

On  the  subject  of  writable  control  stores,  Mr.  Tonik  pointed 
out  the  possibility  of  dynamic  modification  of  the  control,  but  said 
he  was  not  in  favor  of  it.  (This,  of  course,  is  not  quite  the  same 
thing  as  "user11  modification  of  the  control  store  in  a  non-dynamic 
fashion . ) 
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Y.  Chu 

A  Higher-Order  Language  for  Describing  Microprograms 


Dr.  Chu  described  a  language  suitable  for  the  description  of  a 
micromachine  -  its  hardware  registers  and  state  transitions.  A  broad¬ 
brush  description  of  the  language's  main  features  and  syntax  was 
given,  and  a  sample  "program11  in  the  language  was  exhibited.  A 
simulator  (for  testing  micromachine  architectures),  which  accepts  the 
language  as  input,  has  been  constructed. 

Although  it  would  not  be  possible  to  evaluate  the  language  itself 
from  the  level  of  detail  in  the  talk,  it  is  clear  that  such  a  language 
is  valuable  not  only  as  a  tool  for  design  and  design  testing,  but  also 
as  a  means  of  rigorously  defining  a  machine  to  microprogrammers  -  that 
would  be  a  significant  advance  over  functional  (English)  machine 
descriptions  and/or  wiring  diagrams  -  particularly  if  used  to  supplement 
them. 
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G.  Y.  Wang 

Micro -program  Memory  Technology 


Mr.  Wang  discussed  current  developments  in  high-speed  memory 
technology.  The  read-write  characteristics  of  the  technologies  dis¬ 
cussed  are  summarized  in  the  following  chart,  taken  from  the  first 
slide  of  the  presentation. 
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C.  V.  Ramamoorthy 
User  Micro programmable  Computers 


Professor  Ramamoorthy  defined  a  "user  microprogrammable  computer" 
as  one  in  which  the  user  has  some  (restricted)  access  to  the  micropro¬ 
grammable  store.  He  distinguished  two  classes  of  users:  (1)  those  who 
own  the  machine  system  and  (2)  those  who  solve  their  problems  on  the 
system.  The  first  group  he  described  as  interested  primarily  in 
maximum  utilization  and  also  such  specific  problems  as  system  expansion/ 
changeover  transition  problems,  emulation,  user-user  and  user-system 
protection,  automated  surveillance,  and  the  like.  The  second  group 
he  characterized  as  interested  mainly  in  maximum  convenience,  the 
"naturalness"  of  the  languages  provided,  the  production  performance, 
turn-around  and  other  aspects  of  program  production,  and,  possibly, 
real-time  dependency  of  the  problem  program. 

The  user  of  either  class  with  the  desire  and  fortitude  to  formulate 
his  own  solutions  to  his  problems  can  make  good  use  of  microprogramming, 
particularly  from  a  timing  standpoint.  However,  it  was  pointed  out 
that  merely  giving  access  to  the  microprogrammed  store  is  not  enough; 
the  following  requirements  (or,  at  least,  desirable  characteristics) 
were  also  listed: 

1)  A  writable  control  store; 

2)  Reasonable  user  cost; 

3)  Simple  micro -commands ; 

4)  A  language  capable  of  describing  micro-operations; 

5)  Relocatability  and  reentrancy  of  user  microprograms; 

6)  Flexible  addressing  (e.g.  vector,  matrix,  proximity); 

7)  Simplicity  of  the  "visible"  machine; 

8)  Parallel  surveillance  and  user-user,  user-system 
protection. 
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L.  L.  Rakoczi 

Implications  of  Dynamically  Changeable  Microprogram  Memory 

Mr.  Rakoczi  gave  a  spirited  presentation  on  what  he  called  the 
"fourth  generation11  computer  architecture:  the  "machine  within  a 
machine"  -  that  is,  a  dynamically  modifiable  control  store.  Used  in 
a  more  or  less  obvious  way,  such  stores  permit  multiple  emulators  to 
be  run  on  the  same  processor  under  a  central  control  and  with  very 
little  switch-over  time.  Mr.  Rakoczi  cited  several  successful 
emulation  projects  along  these  lines.  More  exciting  was  the  ,,6000-E,, 
machine  which  actually  permits  something  close  to  dynamic  modification 
of  the  control  store  (with  restrictions,  of  course).  The  assembler 
for  this  machine  allows  new  instructions  to  be  defined  in  terms  of  the 
microcommand  sequence  which  realize  them;  these  get  loaded  into  the 
control  store  when  the  "native"  level  program  is  loaded  into  the  main 
store . 


The  talk  touched  off  a  lively  discussion  on  the  subject  of 
writable  control  stores;  it  became  apparent  for  the  first  time  that 
opinions  on  the  matter  differed  widely  and  that  the  subject  would 
occupy  much  of  the  workshop's  attention. 
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SECTION  III 


3.0  SESSION  II 

MICROPROGRAMMING  PRACTICES  AND  TECHNIQUES" 

Chairman:  Dr.  R.  Merwin 
DOD 

This  session  will  concentrate  on  the  mechanics 
and  techniques  for  using  microprogramming  to 
implement  hardware  projects.  Main  topics  of 
discussion  will  be:  control  store  designs, 
simulation  of  microprogrammed  systems,  tech¬ 
niques  for  writing  machine-descriptions,  and 
the  writing  of  associated  microprograms. 

Hardware  and  software  tools  required  for  these 
tasks  and  descriptions  of  specific  approaches  to 
microprogrammed  computer  systems  will  be  discussed. 
Tradeoffs  between  control  and  operational  hardware 
and  a  transformation  technique  for  evaluating 
these,  based  on  microprogramming  techniques,  will 
also  be  covered. 


from  the  Workshop  Bulletin 


G.  E.  Hoernes  and  L.  Hellerman 
Experimental  List-Type  Micro-Code  Assembler 

Messrs.  Hoernes  and  Hellerman  discussed  the  motivation  for,  and 
characteristics  of,  a  "lis t-type"  assembler  to  supplant  the  "box-type" 
assemblers  now  in  use  at  IBM.  The  intention  is  to  utilize  "conventional" 
techniques  and  to  ease  the  transition  from  higher-level  to  micro-code 
for  applications  programmers  with  a  need  to  perform  optimization. 

The  assembler  described  is  itself  coded  in  PL/I.  It  has 
"equation"-format  input  and  a  number  of  output  options  to  satisfy  the 
needs  of  various  users :  the  programmer  who  wants  to  see  the  logic 
flow,  the  engineer  who  wants  to  see  what  bits  are  set  in  the  resulting 
control  word,  and  the  customer  engineer  who  may  want  both. 

The  talk  dealt  mainly  with  problems  peculiar  to  IBM’s  own 
environment.  For  example,  terms  such  as  "edge  characters"  -  meaningless 
except  in  the  context  of  IBM's  "box"  assemblers  -  were  used.  On  the 
whole,  though,  the  talk  was  fairly  well  recieved. 
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J.  R.  Vollbrecnt 

Microprogramming  Design  Aid  System  (MIDAS) 


MIDAS ,  as  described  by  Mr.  Vollbrecht,  appears  to  be  a  standard 
set  ut  microprogramming  utilities  -  an  assembler,  a  simulator,  a  flow 
charter,  a  manufacturing  data  puncher,  etc.,  -  remarkable  mainly  in 
that  they  are  organized  under  a  coherent  "control”  program.  Well- 
cttablished  software  utility  principles  seem  to  have  been  applied  with 
considerable  success. 
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G.  Hoff 

Development  of  a  Microprogramming;  System  for  the  H4200 


Mr.  Hoff's  presentation  was  a  fascinating  (to  a  programmer)  view 
of  microprogramming  from  a  logic  designer's  standpoint.  The  machine 
described  -  the  H4200  -  was  logic  designed  and  microprogrammed  by  the 
same  people,  and  the  impression  was  that  these  were  not,  primarily, 
programmers.  Consequently,  the  project  could  be  considered  a  case 
study  of  the  processor  architecture  that  results  under  such  circum¬ 
stances  . 

The  most  significant  design  constraint  was  that  the  H4200  requires 
a  high  degree  of  parallelism  in  order  to  keep  up  with  the  memory  while 
processing  punctuation-delimited  data  fields.  The  micromachine  command 
structure  arrived  at  to  satisfy  this  requirement  might  be  described 
as  a  M45°"  machine  partaking  of  some  ''horizontal11  (one-bi t-per-gate) 
qualities  and  some  "vertical"  (bus  or  register-oriented)  qualities. 

It  had,  for  example,  curious  six-way  branches  which  do  not  occur 
until  after  the  instruction  following  the  branch  has  already  been 
executed. 
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E.  Stabler 

Microprogram  -  Micro-Operation  Transformations 

Professor  Stabler  described  an  automatic  process  for  determining 
appropriate  state  reductions  -  in  effect  moving  logic  elements  from 
the  control  unit  to  the  operations  unit  of  a  computer.  The  method 
represents  a  theoretical  approach  to  the  important  practical  problem 
of  balancing  hardware-software  tradeoffs. 

It  was  not  clear  that  the  method  had  practical  application  in 
its  present  form,  inasmuch  as  the  sequential-state  description  of  a 
typical  process  (say,  a  floating-add)  in  a  real  computer  would  be  a 
formidable  task,  and  in  any  case  one  cannot  be  sure  that  the  reduced 
process  is  unique  and  independent  of  the  original  detailed  process. 
Nevertheless,  the  study  has  potential  practical  use  as  well  as 
theoretical  interest . 
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G.  S.  Badger 

The  Use  of  Microprogramming  in  a  Course  in  Computer 

Operating  Systems 

It  would  seem  that  a  first  course  in  operating  systems  -  on  a 
"dirty"  machine  -  would  be  hardly  the  place  for  the  subject  of  micro¬ 
programming  to  come  up.  Mr.  Badgerfs  reasons  for  making  the  ”^udy  of 
microprogramming  an  integral  part  of  such  a  course  summarize  the  view 
of  microprogramming  as  a  medium  of  communication,  especially  pedagogical 
communication : 

1)  The  breakdown  of  instructions  into  micro¬ 
instructions  gives  some  idea  of  instruction 
commonality ; 

2)  The  principles  of  interpreter  architecture 
are  illustrated; 

3)  A  non-hardware  description  of  the  machine 
is  afforded  by  the  microprogram; 

4)  An  idea  of  what  is  time-consuming  for  the 
machine  to  do  may  be  gained  from  putting 
together  a  microprogram; 

5)  The  logical  arbitrariness  of  the  hardware- 
software  "line"  is  illustrated,  and  the 
practical  considerations  that  go  into 
drawing  this  line  are  more  fully  appreciated 
after  a  microprogramming  exercise. 
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H.  C.  Forsdick  and  Dr.  R.  Merwin 
Microprogram  Control  Design  and  Simulation  System 

Dr.  Merwin,  speaking  for  Mr.  Forsdick,  described  a  system 
composed  of  a  hardware  description  language,  actual  microcode 
language,  and  simulation  language,  useful  as  a  pedagogical  tool  and 
design  experimentation  aid. 
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SECTION  IV 


4.0  SESSION  III 

"APPLYING  MICROPROGRAMMING  TECHNIQUES" 

Chairman:  Mr.  J.  D.  Babcock 
Allen -Babcock 

(represented  by  P.  R.  DesJardins,  Allen-Babcock) 

The  advent  of  read -only-store  computer  design 
has  suggested  the  ability  to  "extend"  the  use 
of  such  a  machine  beyond  that  of  a  general- 
purpose  production  tool.  This  session  will 
concentrate  on  projects  in  which  the  use  of 
micro-programmed  machine  resulted  in  an  extended- 
machine  (as  opposed  to  a  limited -machine)  design. 

The  main  discussion  will  present  specific 
projects,  including  statistical  reports  on  the 
application  (thus,  why  was  it  microprogrammed 
in  the  first  place),  costs  of  the  programming 
effort,  and  the  required  training  and  back¬ 
ground  needed  for  the  implementors.  Some  emphasis 
will  be  directed  toward  anticipating  future 
needs  in  implementing  microprogramming  applications. 
This  information  will  be  based  on  the  experience 
gained  on  the  projects  described. 

—  from  the  Workshop  Bulletin 
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R.  T.  Borovec 


A  Report  on  the  Use  of  Microprogramming  for  the 

Illiac  III  Image  Processor 

The  session  opened  with  a  presentation  by  R.  T.  Borovec  on  the 
Illiac  III  Image  Processor.  Developed  for  high-energy  physics 
applications,  it  is  now  used  also  in  biological  and  weather  photo 
analysis.  The  central  control  point  or  Mpattern  articulation  unit 
(PAU)"  is  microprogrammed;  this  unit  was  the  focus  for  most  of  the 
talk. 


Interesting  features  of  the  Image  Processor  are  a  transfer 
memory  accessible  either  as  1024  48-bit  words  or  48  1024-bit  Words 
and  a  32  x  32  bit  "iterative*  array"  which  may  be  uSed  as  an  associative 
memory.  The  organization  may  be  depicted  as  follows: 


^  =  Control  Path 


=  Data  Path 
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P.  R.  DesJardins 


The  Use  of  Microprogramming  to  Enhance  Machine  Performance  of 

a  Time -Sharing  Programming  System 

Mr.  DesJardins  described  an  extension  of  twenty-two  instructions 
to  the  360/50  manufacturer-supplied  set.  The  instructions  described 
were  in  support  of  an  interactive  time-sharing  system  (RUSH).  Those 
singled  out  as  having  the  most  payoff  were  variants  of  a  chained  list 
search.  Other  'list1  instructions,  "reentrant  utility"  instructions, 
and  genuine  floating  decimal  instructions  were  also  discussed.  (The 
microcode  is  available  from  IBM  as  RPQ*s.) 
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D.  Boyle 

Microprogramming  of  Data  Logging  and  Data  Reducing  Equipment 


Mr.  Boyle  described  a  simple  processor  capable  of  driving  and 
sequencing  the  steps  of  a  physical  experiment.  The  system  could  be 
characterized  as  a  sort  of  "immediate*1  process  control,  or  a  computer 
with  radars,  A-D  converters,  and  the  like  as  components  but  largely 
lacking  in  the  usual  things  such  as  memory  or  arithmetic  units. 

Mr.  Boyle  himself  said  the  system  was  simple  and  did  not  claim  that  a 
sophisticated  or  advanced  application  of  microprogramming  was  involved. 
Some  discussion  was  triggered  by  a  remark  from  I.  Flores  to  the  effect 
that  the  system  was  too  simple  to  be  interesting  and  not  even  micro¬ 
programming  -  a  view  not  generally  supported  by  those  present. 
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C.  L.  Mathis 

Emulating  the  7094  on  the  360/85 


Mr.  Mathis  of  IBM  described  various  approaches  to  the  specific 
problem  of  7094  emulation  on  the  360/85,  with  a  performance  goal  of 
doubling  the  7094  speed.  Two  approaches  were  discussed,  (1)  a  "sub- 
routine  interpretive  mode”  involving  a  slight  extension  of  the  360/85 
instruction  set  for  decoding  7094  instruction  and  executing  a  few  of 
the  more  frequently  used  ones,  and  (2)  a  "microprogram  interpretive 
mode"  wherein  sequences  of  7094  instructions  may  be  executed  in  micro¬ 
code.  Approach  (2)  required  various  ad  hoc  additions  to  the  360/85 
hardware,  for  example,  an  inhibit  of  the  instruction  look-ahead. 
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B.  Caruthers 

Microprogramming  to  Support  FORTRAN  Functions 

When  an  instruction  set  is  implemented  without  "excess  garbage" 
from  a  FORTRAN  point  of  view  -  the  result  is  a  faster  running  FORTRAN, 
This  perhaps  predictable  consequence  was  documented  by  Mr.  Carlithers 
in  his  discussion  of  such  an  instruction  set.  Speed  was  improved  by 
the  following  factors: 


£  2  in  general  computation; 

5  to  7  in  subscript  calculation; 
hundreds"  in  computation  of  exponentials. 
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H.  Lawson 

Microprogrammed  Higher  Level  Language  Computers 


Mr.  Lawson  opened  with  a  set  of  definitions  (with  credits  to 
Julien  Green)  that  included:  Microprogramming  is  programming  the 
interpreter11.  Mr.  Lawson  went  on  to  present  the  case  for  micropro¬ 
grammed  truly  higher-level  languages.  The  reasons  he  advanced  and 
the  general  properties  he  postulated  for  such  a  language  seemed  to 
imply  something  on  the  order  of  PL/I  or  even  beyond.  The  benefits 
to  be  derived  were  stated  to  be  as  follows: 

(1)  Simplicity  -  fewer  levels  of  language 
to  cope  with; 

(2)  Efficiency  -  "super11  operations  may  be 
performed  in  high-speed  control; 

(3)  Comparability  -  historically,  more  success 
has  been  realized  with  higher-level  lan¬ 
guages  than  with  machine  languages. 
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SECTION  V 


5.0  SESSION  IV 

'•SELECTED  SHORTS  ON  THE  PAST  AND  FUTURE'1 

Chairman:  Mr.  A.  Siegel 
Decision  Systems 


This  session  will  assess  the  extent  and  direction, 
if  any,  of  the  influence  of  microprogramming 
concepts  upon  the  design  and  utilization  role  of 
user-prepared  microprograms,  the  relationship 
between  engineering  and  programming,  the  impli¬ 
cations  of  writable  control  storage,  and  the 
feasibility  of  standardizing  micro -processors 
and/or  microprogramming  languages. 

Based  upon  their  own  experience,  all  partici¬ 
pants  will  be  encouraged  to  express  their  views 
on  the  benefits  or  dangers  of  the  more  widespread 
use  of  microprogramming.  The  discussion  is 
expected  to  culminate  in  meaningful  conclusions 
concerning  the  future  of  microprogramming  and 
its  role  as  a  lasting  influence,  or  a  passing  fad, 
in  computer  technology. 

Since  vigorous  discussion  is  anticipated,  partici¬ 
pants  who  wish  to  ensure  themselves  of  an  oppor¬ 
tunity  to  speak  may  do  so  by  contacting  the  session 
chairman  prior  to  the  meeting. 

—  from  the  Workshop  Bulletin 
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Proceedings 


Session  IV  was  by  design  an  open-floor  session  with  only  short, 
informally  scheduled  and  informally  delivered  talks  from  the  rostrum. 

Dan  Zatyko  of  General  Electric  lucidly  illustrated  the  problems 
that  arise  when  microprogramming  is  defined  in  terms  of  language  level 
e.g.  as  “implementing  control  logic11  -  because, of  course,  any  level 
can  be  thought  of  as  interpreting  and  executing  a  “language'1  at  a 
higher-level.  He  referred  to  the  level  below  microprogramming  as 
“picoprogramming"  -  a  term  which  hasn't  caught  on,  at  least  not  yet.* 

Julien  Green  characterized  micromachines  by  such  things  as  their 
sparsity  of  registers  and  the  treatment  of  main  memory  as  an  I/O  device 

Still  other  definitions  of  microprogramming  were  advanced,  some 
in  terms  of  hardware  (“regular"  vs.  “irregular"  memories),  and  others 
in  terms  of  characteristics  such  as  parallelism.  This  writer  offered 
the  view  that  “micro"  is,  after  all,  a  quantitative  prefix  and  that 
precise  definition  was  neither  possible  nor  desirable  -  just  as  a  line 
cannot  be  drawn  between  “big"  and  “little".  This  failed  to  settle 
the  question,  but  at  least  the  discussion  moved  on  to  other  questions 
soon  thereafter. 

Bob  Rosin  of  SUNY  exhibited  the  architecture  of  a  hypothetical 
computer  he  uses  for  pedagogical  purposes  and  for  which  a  simulator  has 
been  built. 

C.  Billings  of  Honeywell  presented  the  case  for  a  higher-level 
language  to  be  compiled  into  microcode  (analogously  to  FORTRAN  and 
machine  code).  The  arguments  were  the  standard  ones  for  higher-level 
languages.  When  he  finished  and  asked  for  opinions,  the  consensus 
seemed  to  be  that  efficiency  problems  would  make  such  languages 
impractical.  Of  course,  this  was  the  strongest  argument  against 
FORTRAN  in  its  early  days  also,  and  time  has  shown  the  argument  to 
be  hollow.  Nevertheless,  the  two  cases  are  not  quite  equivalent  and 
so  the  issue  was  not  resolved. 


but  see  Briley,  P.  E. ,  “Picoprogramming :  A  New  Approach  to  Internal 
Computer  Control",  AFIPS  1965  Fall  Joint  Computer  Conference, 
pp.  193-98;  May-June  1966. 
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The  topic  of  writable  control  stores  prompted  a  vigorous  floor 
debate  on  the  advisability  of  allowing  users  to  modify  the  control  store 
a  "freedom  vs.  security11  question,  in  this  writer*  s  opinion.  Not 
surprisingly,  manufacturers  expressed  a  reluctance  to  offer  this 
facility,  envisioning  a  documentation  and  maintenance  nightmare.  One 
even  expressed  concern  that  users  would  "hang  themselves**  (perhaps 
with  too  much  rope  memory?).  It  seemed  clear  from  the  discussion  that 
writable  control  stores  are  destined  to  come  very  much  into  demand, 
and  that  the  technology  governing  their  proper  use  will  have  to  advance 
rapidly. 
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